-
Notifications
You must be signed in to change notification settings - Fork 775
*: rename serialization.md -> config.md #305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
schema/spec_test.go
Outdated
| validate(t, "../manifest.md") | ||
| } | ||
|
|
||
| func TestValidateSerialization(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Config??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
|
@vbatts Looks like there are some whitespace problems. |
|
fixed. Not sure why newer |
image-layout.md
Outdated
| The OCI Image Layout is a slash separated layout of OCI content-addressable blobs and [location-addressable](https://en.wikipedia.org/wiki/Content-addressable_storage#Content-addressed_vs._location-addressed) references (refs). | ||
| This layout MAY be used in a variety of different transport mechanisms: archive formats (e.g. tar, zip), shared filesystem environments (e.g. nfs), or networked file fetching (e.g. http, ftp, rsync). | ||
| Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem serializations in the correct order, and then converting the image configuration into an OCI Runtime config.json. | ||
| Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the [filesystem layers](./layer.md) in the correct order, and then converting the image configuration into an OCI Runtime config.json. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for ./, just use [filesystem layers](layer.md).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we've been through this. This is for explicit relative path. It's not a rule, but many tools rely on such to determine that it is a relative path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whatever
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Tue, Sep 13, 2016 at 02:12:47PM -0700, Vincent Batts wrote:
-Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem serializations in the correct order, and then converting the image configuration into an OCI Runtime config.json.
+Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem layers in the correct order, and then converting the image configuration into an OCI Runtime config.json.we've been through this. This is for explicit relative path. It's
not a rule, but many tools rely on such to determine that it is a
relative path.
Can you point to such a tool? If we want to require explicit ./,
we'll want a new PR to update many existing links.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
go build
On Tue, Sep 13, 2016 at 5:23 PM W. Trevor King [email protected]
wrote:
In image-layout.md
#305 (comment)
:@@ -2,7 +2,7 @@
The OCI Image Layout is a slash separated layout of OCI content-addressable blobs and location-addressable references (refs).
This layout MAY be used in a variety of different transport mechanisms: archive formats (e.g. tar, zip), shared filesystem environments (e.g. nfs), or networked file fetching (e.g. http, ftp, rsync).
-Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem serializations in the correct order, and then converting the image configuration into an OCI Runtime config.json.
+Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem layers in the correct order, and then converting the image configuration into an OCI Runtime config.json.On Tue, Sep 13, 2016 at 02:12:47PM -0700, Vincent Batts wrote: > -Given an
image layout a tool can convert a given ref into a runnable OCI Image
Format by finding an appropriate manifest from the manifest list, unpacking
the filesystem serializations in the correct order, and then converting the
image configuration into an OCI Runtime config.json. > +Given an image
layout a tool can convert a given ref into a runnable OCI Image Format by
finding an appropriate manifest from the manifest list, unpacking the
filesystem layers in the correct order, and then converting
the image configuration into an OCI Runtime config.json. we've been through
this. This is for explicit relative path. It's not a rule, but many tools
rely on such to determine that it is a relative path.
Can you point to such a tool? If we want to require explicit ./, we'll
want a new PR to update many existing links.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opencontainers/image-spec/pull/305/files/7457e6cfb9e8a70e0c0823e7b2ffc24d5b0ca3ab#r78647065,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEF6f8oGVRuL5XudyYAc_obJhwUnV2fks5qpxQ9gaJpZM4J8CpQ
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Tue, Sep 13, 2016 at 02:24:45PM -0700, Vincent Batts wrote:
-Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem serializations in the correct order, and then converting the image configuration into an OCI Runtime config.json.
+Given an image layout a tool can convert a given ref into a runnable OCI Image Format by finding an appropriate manifest from the manifest list, unpacking the filesystem layers in the correct order, and then converting the image configuration into an OCI Runtime config.json.go build
‘go build’ parses this Markdown?
manifest.md
Outdated
|
|
||
| This REQUIRED property references a configuration object for a container, by digest. | ||
| The referenced configuration object is a JSON blob that the runtime uses to set up the container, see [Image JSON Description](serialization.md#image-json-description). | ||
| The referenced configuration object is a JSON blob that the runtime uses to set up the container, see [Image JSON Description](config.md#image-json-description). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that the files are split, we may want to drop the fragment here. If config.md is so big that you want to link to a subsection as the spec for the format, we should probably trim config.md ;).
config.md
Outdated
|
|
||
| ## Image JSON Description | ||
|
|
||
| Here is an example image JSON file: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update the title to:
Image Configuration
678aac7 to
5f8edee
Compare
Closes: opencontainers#283 Signed-off-by: Vincent Batts <[email protected]>
| </dl> | ||
|
|
||
| ## Image JSON Description | ||
| ## Image Configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant the H1 at the top of this file. This whole file is about that configuration, right?
This didn't make it into 17c1f00 (*: rename serialization.md -> config.md, 2016-09-13, opencontainers#305), but I think we still want it [1,2,3]. While I was touching headers, I shifted the informative example section down under the normative property definitions, and move the normative whitespace rule up out of the example section. [1]: opencontainers#255 (comment) [2]: opencontainers#305 (comment) [3]: opencontainers#305 (comment) Signed-off-by: W. Trevor King <[email protected]>
This didn't make it into 17c1f000 (*: rename serialization.md -> config.md, 2016-09-13, #305), but I think we still want it [1,2,3]. While I was touching headers, I shifted the informative example section down under the normative property definitions, and move the normative whitespace rule up out of the example section. [1]: opencontainers/image-spec#255 (comment) [2]: opencontainers/image-spec#305 (comment) [3]: opencontainers/image-spec#305 (comment) Signed-off-by: W. Trevor King <[email protected]>
This didn't make it into 17c1f000 (*: rename serialization.md -> config.md, 2016-09-13, #305), but I think we still want it [1,2,3]. While I was touching headers, I shifted the informative example section down under the normative property definitions, and move the normative whitespace rule up out of the example section. [1]: opencontainers/image-spec#255 (comment) [2]: opencontainers/image-spec#305 (comment) [3]: opencontainers/image-spec#305 (comment) Signed-off-by: W. Trevor King <[email protected]>
This didn't make it into 17c1f000 (*: rename serialization.md -> config.md, 2016-09-13, #305), but I think we still want it [1,2,3]. While I was touching headers, I shifted the informative example section down under the normative property definitions, and move the normative whitespace rule up out of the example section. [1]: opencontainers/image-spec#255 (comment) [2]: opencontainers/image-spec#305 (comment) [3]: opencontainers/image-spec#305 (comment) Signed-off-by: W. Trevor King <[email protected]>
This didn't make it into 17c1f000 (*: rename serialization.md -> config.md, 2016-09-13, #305), but I think we still want it [1,2,3]. While I was touching headers, I shifted the informative example section down under the normative property definitions, and move the normative whitespace rule up out of the example section. [1]: opencontainers/image-spec#255 (comment) [2]: opencontainers/image-spec#305 (comment) [3]: opencontainers/image-spec#305 (comment) Signed-off-by: W. Trevor King <[email protected]>
This didn't make it into 17c1f000 (*: rename serialization.md -> config.md, 2016-09-13, #305), but I think we still want it [1,2,3]. While I was touching headers, I shifted the informative example section down under the normative property definitions, and move the normative whitespace rule up out of the example section. [1]: opencontainers/image-spec#255 (comment) [2]: opencontainers/image-spec#305 (comment) [3]: opencontainers/image-spec#305 (comment) Signed-off-by: W. Trevor King <[email protected]>
Closes: #283
Signed-off-by: Vincent Batts [email protected]